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REMARKS/ARGUMENTS 

Rejection under 35 USC § 1 12 

In the Office Action, Claims 11 and 15-17 are rejected under 35 USC § 112, 
second paragraph, as being indefinite for failing to particularly point out and distinctly 
claim the subject matter which the applicant regards as the invention. The Office Action 
objected to Claim 11 for antecedent basis of "the customer virtual LAN" in lines 11-12 
and "the address memory file" in line 20. The antecedent basis for these terms and other 
terms has been corrected in claim 11. As such, reconsideration and withdrawal of the 
rejection under 35 USC § 1 12, second paragraph is respectfully requested. 

Rejection under 35 USC $ 103 (a) 

The Office Action rejcted Claims 1, 5-7, 1 1 and 15-17 under 35 USC § 103 (a) as 

being unpatentable over U.S. Pub. No. 2005/0259597 to Benedetto et al. (the Benedetto 

reference) in view of U.S. Pub. No. 2002/0147800 to Gai et al. (the Gai reference). 

Applicants respectfully traverse the rejection of the claims under 35 U.S.C. § 103(a) 

because the Office Action has failed to provide a prima facie case of obviousness of the 

claims in view of the cited references for the reasons stated below. 

The specification of corresponding US Published Application No. 20040174828 

states in paragraphs 1 1 and 12 that: 

"[0011] Topology changes in the Customer VLAN can also require 
changes in the MAC address tables in the bridges of the provider network. 
A previous proposal allows snooping on all TCNs generated within the 
customer domain, and taking action indiscriminately. Each time a TCN is 
generated, the provider domain unlearns (flushes the MAC table of each 
bridge) and re-learns all the addresses. Re-learning the MAC address at 
each bridge is a costly and time-consuming operation. 
[0012] Therefore, a need has arisen for an efficient method of taking 
action inside the provider domain responsive to TCNs received from the 
customer domain. 

The specification of corresponding US Published Application No. 20040174828 states in 
paragraphs 33 through 37 that: 
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[0033] FIG. lb illustrates a topology change that will affect the MAC 
address tables of the bridges in Site A, but does not affect the MAC 
address table in any of the provider bridges. In FIG. lb, the CB2-CB3 link 
is activated and the CE1-CB1 link is blocked. TCNs will be generated 
accordingly within the Customer VLAN 18 to indicate that changes have 
been made to the topology. TCNs are generated as a BPDU (Bridge 
Protocol Data Unit); if the TCN flag is set in a BDPU, it is interpreted as a 
TCN. The MAC address tables for CE1 and CB2 must be changed in 
response to these TCNs, but the forwarding address in the provider bridges 
remain valid with regard to addresses X and Y. Therefore, unlearning 
address in the provider domain due these TCNs would be wasteful. 

[0037] The flowchart of FIG. 2a determines whether a TCN was generated 
for a topology change in the customer domain that may require 
unlearning/relearning operations in the provider domain, by checking for 
contradictory MAC address or new MAC addresses. However, receiving a 
new MAC address does not conclusively mean that the new address was 
received due to the topology change indicated by the received TCN. A 
new MAC address could also indicate that a MAC address was not 
previously active. Thus, an unlearning operation could be unnecessary." 
The specification describes that in known solutions, each time a TCN is generated from a 
customer domain, a provider domain unlearns (flushes the MAC table of each bridge) and 
re-leams all the addresses. However, re-learning the MAC address at each bridge is a 
costly and time-consuming operation. An embodiment of the specification describes that 
a TCN generated from a customer domain may not require flushing of the MAC 
addresses in the provider domain when the topology change in the customer domain does 
not affect paths of data units through the provider domain. Thus, an embodiment 
determines whether the MAC addresses need to be flushed and relearned in a provider 
domain in response to a TCN from a customer domain. If the topology change in the 
customer domain does not affect paths of data units through the provider domain, then 
the MAC addresses in the address memory file are not flushed and relearned. 
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Independent Claim 1 and dependent claims 5 through 7 

The Office Action has failed to provide a prima facie case that the combination of 
the Benedetto reference and the Gai reference disclose or make obvious the elements of 
claim 1, inter alia, of, "in response to receiving a TCN from the customer network, 
determining whether the topology change in the one or more of the customer virtual LAN 
segments does not affect paths of data units through the provider network by monitoring 
end host media access control (MAC) addresses in data units received from the customer 
network for a predetermined time period," and "in response to determining the a topology 
change in the one or more of the customer virtual LAN segments do not affect paths of 
data units through the provider network upon receiving the TCN from the customer 
network, storing the new end host MAC addresses of data units received from the 
customer network in the predetermined time period in the MAC address memory file 
without flushing the MAC address memory file." 

1. Combination Fails to Disclose Elements of Claim 1 

In paragraph 2, on pages 3-6, the Office Action asserts that the combination of the 
the Benedetto reference and the Gai reference each disclose certain elements of claim 1 . 
The Office Action has misinterpreted the teachings of these references. First with respect 
to the Benedetto reference, the Benedetto reference states in paragraph 17 that: 

If a bridge stops receiving BPDU messages on a given port (indicating a 
possible link or device failure), it will continue to increment the respective 
message age value until it reaches the maximum age threshold. The bridge 
will then discard the stored BPDU information and proceed to re-calculate 
the root, root path cost and root port by transmitting BPDU messages 
utilizing the next best information it has. The maximum age value used 
within the bridged network is typically set by the root, which enters the 
appropriate value in the maximum age field 126 of its transmitted BPDU 
messages 100. Neighboring bridges similarly load this value in their 
BPDU messages, thereby propagating the selected value throughout the 
network. The default maximum age value under the IEEE standard is 
twenty seconds, [emphasis added] 
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The Benedetto reference clearly indicates in this paragraph 17 that a bridge will discard 
stored BPDU information if a bridge stops receiving BPDU messages on a given port for 
a maximum age value threshold. In paragraph 19, the Benedetto reference reiterates this 
disclosure and states that (emphasis added): 

To prevent bridges from distributing messages based upon incorrect 
address information, bridges quickly age-out and discard the "old" 
information in their filtering databases. More specifically, upon detection 
of a change in the active topology, a bridge begins transmitting Topology 
Change Notification Protocol Data Unit (TCN-PDU) messages on its root 
port. The format of the TCN-PDU message is well known (see IEEE 
802. ID standard) and, thus, will not be described herein. A bridge 
receiving a TCN-PDU message sends a TCN-PDU of its own from its root 
port and sets the TCA flag 1 12 in BPDUs that it sends on the port from 
which the TCN-PDU was received, thereby acknowledging receipt of the 
TCN-PDU. By having each bridge send TCN-PDUs from its root port, the 
TCN-PDU is effectively propagated hop-by-hop from the original bridge 
up to the root. The root confirms receipt of the TCN-PDU by setting the 
TC flag 114 in the BPDUs that it subsequently transmits for a period of 
time. Other bridges, receiving these BPDUs, note that the TC flag 1 14 has 
been set, thereby alerting them to the change in the active topology. In 
response, bridges significantly reduce the aging time associated with their 
filtering databases which, as described above, contain destination 
information corresponding to the entities within the network. Specifically, 
bridges replace the default aging time of five minutes with the forwarding 
delay time, which by default is fifteen seconds. Information contained in 
the filtering databases is thus quickly discarded. 

Thus, in response to a TCN-PDU, the Benedetto reference discloses that information 
contained in the filtering databases is thus quickly discarded. There is no disclosure in 
the Benedetto reference of in response to receiving a TCN from the customer network, 
determining whether the topology change in the one or more of the customer virtual LAN 
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segments does not affect paths of data units through the provider network by monitoring 
end host media access control (MAC) addresses in data units received from the customer 
network for a predetermined time period. Furthermore, there is no disclosure in the 
Benedetto reference of in response to determining the a topology change in the one or 
more of the customer virtual LAN segments do not affect paths of data units through the 
provider network upon receiving the TCN from the customer network, storing the new 
end host MAC addresses of data units received from the customer network in the 
predetermined time period in the MAC address memory file without flushing the MAC 
address memory file. 

The Gai reference also fails to disclose these elements of claim 1. First, the Gai 
nowhere discloses receiving a TCN from the customer network, determining whether the 
topology change in the one or more of the customer virtual LAN segments does not affect 
paths of data units through the provider network. The Gai reference only discusses a 
method in case of failure of links between an access switch and backbone switch in a 
provider network. The Gai reference states in paragraph 58 that: 

[0058] Should a change occur in the network 100, such as a failure 
disabling the link coupled to a root port of an access switch, the affected 
access switch will be able to rapidly reconfigure the network 100 without 
the significant interruption or message flooding experienced through 
conventional operation of the spanning tree algorithm. With reference to 
switch 114, for example, assume that port number three, which is coupled 
to backbone switch 122, is the root port for switch 114 and thus in the 
forwarding state. Pursuant to the Enable_Uplinkfast command 330, port 
numbers two and four, which also connect switch 114 to the backbone 
switches (i.e., backbone switches 122 and 124), are in the blocked state. If 
the link 128 coupled to the port number three at switch 114 fails, either 
one of these two other ports (i.e., port numbers two or four) will 
immediately transition to the forwarding state and begin receiving and 
sending messages. 

As described, the Gai reference describes that in the event of a failure of a link between 
the access switch and backbone switch, redundant links between the access switch and 
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backbone switch will transition to a forwarding state. The Gai reference nowhere 
discloses receiving a TCN from the customer network, determining whether the topology 
change in the one or more of the customer virtual LAN segments does not affect paths of 
data units through the provider network. 

On page 6, second full paragraph, the Office Action asserts that the Gai reference 
discloses the elements in claim 1 of in response to determining a topology change in one 
or more of the customer LAN segments do not affect paths of data units through the 
provider network, storing the new end host MAC address of data units received from the 
customer network in the predetermined time period in the MAC address memory file 
without flushing the MAC address memory file. The Office Action states that: 
"(Para. [0026] The transition to a new forwarding port is accomplished 
without other devices having to discard contents of their filtering databases 
- where a filtering database is a MAC address memory file and when a new 
forwarding port is learned, it is stored)." 
However, the Office Action has misconstrued the Gai reference and taken its words out 
of context to twist their true meaning. 

The Gai reference states that in the event of a failure of a link between the access 
switch and backbone switch, redundant links between the access switch and backbone 
switch will transition to a forwarding state. When the redundant links between the access 
switch and backbone switch transition to a forwarding state, the Gai reference describes 
that: 

"[0061] FIG. 3D is a flow diagram of a rapid reconfiguration process 340 
following a link failure according to the present invention. In response to 
the detection of a failure at port number three (the root port), indicated at 
block 342, rapid reconfiguration entity 234 at switch 214 selects a backup 
port to become the new root port, as shown at box 344.. . . 
[0063] Rapid reconfiguration entity 234, at block 346, then directs the 
spanning tree state machine engine 236 to immediately transition the 
selected back-up port (e.g., port number four) to the forwarding state. That 
is, the spanning tree engine 236 does not transition the selected back-up 
port between the listening or learning states. Instead, the selected back-up 
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port transitions directly to the forwarding state under the direction of rapid 
reconfiguration entity 234, and switch 114 immediately begins 
transmitting and receiving messages through this newly activated trunk 
port 119 (e.g., port number four). 

[0065] Nonetheless, the transition at access switch 114 from initial root 
port number three to back-up root port number four may cause entities to 
appear to "move" relative to other devices. Thus, the identity of the new 
root port (e.g., port number four) must be propagated to the other devices, 
such as access switches 115-116 and backbone switches 120-125 to 
prevent messages from being lost or misdirected. Switch 114, via rapid 
reconfiguration entity 234, preferably informs the other devices of its 
new forwarding port by transmitting dummy multicast packets through 
the new port, as indicated at block 348. 

[0067] Since the multicast message 400 having the source address of 
server 112a was received by backbone switch 124 at a new source port, 
this new location information is entered by backbone switch 124 into its 
filtering database, replacing the previous information that was stored 
therein. Thereafter, if backbone switch 124 receives a message intended 
for server 1 12a, it will use this new destination port and the message will 
be received at port number four of switch 114, which is now capable of 
receiving and forwarding messages. Accordingly, the dummy multicast 
message 400 effectively apprises backbone switch 124 of the change in 
forwarding ports that occurred at access switch 114. Backbone switch 
124 distributes the multicast message 400 through all of its forwarding 
ports so that other devices, as necessary, may learn of the new forwarding 
port (i.e., port number four) at access switch 1 14." 
The Gai reference thus describes that a dummy multicast message is transmitted by the 
new forwarding port of the access switch to the backbone switch, and this dummy 
multicast message apprises backbone switch 124 of the change in forwarding ports that 
occurred at access switch 1 14. 
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The Gai reference nowhere discloses receiving a TCN from the customer 
network, determining whether the topology change in the one or more of the customer 
virtual LAN segments does not affect paths of data units through the provider network. 
As such, there is no disclosure in the Benedetto reference of in response to receiving a 
TCN from the customer network, determining whether the topology change in the one or 
more of the customer virtual LAN segments does not affect paths of data units through 
the provider network by monitoring end host media access control (MAC) addresses in 
data units received from the customer network for a predetermined time period. 
Furthermore, there is no disclosure in the Benedetto reference of in response to 
determining the a topology change in the one or more of the customer virtual LAN 
segments do not affect paths of data units through the provider network upon receiving 
the TCN from the customer network, storing the new end host MAC addresses of data 
units received from the customer network in the predetermined time period in the MAC 
address memory file without flushing the MAC address memory file. 

2. Combination Fails to Suggest Elements of Claim 1 

In paragraph 2, on pages 6-7, the Office Action asserts that the combination of the 
the Benedetto reference and the Gai reference suggest the elements of claim 1 stating 
that: 

"It would have been obvious to one of ordinary skill in the art at the time 
of the invention to modify Benedetto to include storing a new address in 
the address memory file without flushing the address memory file as 
taught by Gai in order to more efficiently update a route cache." 
However, even if Benedetto is updated to include the teaching of Gai, it would not 
disclose the elements of the claims. Figure 2 of the Benedetto reference illustrates almost 
the same network configuration as shown in Figure 1 of the Gai reference. Thus, the 
combination of the Benedetto reference and the Gai reference would only teach that the 
access switch 224 in Figure 2 of Benedetto (similar to the access switch 114 in Figure 1 
of the Gai reference) in the event of a failure of a link 232, redundant links 232 between 
the access switch 224 and backbone switch 220-223 (similar to backbone switch 124 in 
Figure 1 of the Gai reference will transition to a forwarding state, and that a dummy 



14 



Application No. 1 0/73 7,2 1 9 



Docket No. AL139156 



multicast message is transmitted by the new forwarding port of the access switch 224 to 
the backbone switch 220-223, and this dummy multicast message apprises backbone 
switch 220-223 of the change in forwarding ports that occurred at access switch 224. 

In fact, since the Bendetto teaches that in response to a TCN-PDU, information 
contained in the filtering databases is thus quickly discarded, the combination of the 
Benedetto reference and the Gai reference teaches away from the elements of claim 1 . 

3. Conclusion of No Prima Facie Case of Obviousness 

In conclusion, the Office Action has failed to show how the the combination of 
the Benedetto reference and the Gai reference discloses or makes obvious the elements of 
claim 1 under 35 U.S.C. §103. Instead, the combination of the Benedetto reference and 
the Gai reference teach away from the elements of claim 1 . It seems that keywords in 
claim 1 and teachings of the specification were used to piecemeal together citations from 
the references that actually teach away from claim 1 in the rejection under 35 U.S.C. 103. 
"The court must be ever alert not to read obviousness into an invention on the basis of the 
applicant's own statements; that is, we must view the prior art without reading into that 
art appellant's teachings." Application of Nomiya, 184 U.S.P.Q. 607, 612 (Cust. & 
Pat.App. 1975). The citation of the specification's own teachings to argue obviousness 
over prior art is improper. In re Dembiczak, 175 F.3d 994, 999, (criticizing hindsight 
syndrome wherein that which only the inventor taught is used against the teacher). 

Claims 5-7 are dependent upon claim 1 and introduce additional patentable 
subject matter. The applicant believes that the reasons that distinguish claim 1 over the 
present rejection are applicable in distinguishing claims 5-7 over the same rejection. 

Independent Claim 1 1 and dependent claims 15 through 17 

For similar reasons as stated with respect to claim 1, the Office Action has failed 
to prove that the combination of the Benedetto reference and the Gai reference discloses 
or makes obvious the elements of claim 11. Claims 15 through 17 add further patentable 
matter to Claim 11 and thus are further differentiated and patentable under 35 U.S.C. 
§103 over the combination of the Benedetto reference and the Gai reference. 
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Independent Claim 23 and dependent claim 24 

For similar reasons as stated with respect to claim 1, the Office Action has failed 
to prove that the combination of the Benedetto reference and the Gai reference discloses 
or makes obvious the elements of claim 23. Claim 24 adds further patentable matter to 
Claim 23 and thus is further differentiated and patentable under 35 U.S.C. §103 over the 
combination of the Benedetto reference and the Gai reference. 

CONCLUSION 

For the foregoing reasons, the applicant believes that claims 1, 5-7, 11 and 15-17 
and 23-24 are in condition for allowance and respectfully request that they be passed to 
allowance. 

The Applicant hereby rescinds any disclaimer of claim scope made in the parent 
application or any predecessor application in relation to the instant application. The 
Examiner is advised that any such previous disclaimer and the prior art that it was made 
to avoid, may need to be revisited. Further, the claims in the instant application may be 
broader than those of a parent application. Moreover, the Examiner should also be 
advised that any disclaimer made in the instant application should not be read into or 
against the parent application. 

No additional fees are believed to be due. In the event that additional fees are due 
or a credit for an overpayment is due, the Commissioner is hereby authorized to charge 
any additional fees or credit any overpayment to Garlick Harrison & Markison Deposit 
Account No. 50-2126. 



16 



Application No. 1 0/73 7,2 1 9 



Docket No. AL139156 



The Examiner is invited to contact the undersigned by telephone or facsimile if 
the Examiner believes that such a communication would advance the prosecution of the 
present invention. 

RESPECTFULLY SUBMITTED, 

By: /Jessica W. Smith, Reg. No. 39,884/ 
Jessica W. Smith 
Garlick Harrison & Markison 
P. O. Box 160727 
Austin, TX 78716-0727 
Phone: (972) 240-5324 
Fax: (888) 456-7824 
email: ismithfSjtexaspatents.com 
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